23 replies to this topic

[RJC]

Hi everyone - this is my first post, so I apologize in advance if it's been asked a zillion times, and if it's in the wrong place..

I'm currently in the process of switching shopping carts. I will be switching servers, but not domains. I'm hoping to FIRST temporarily (VERY temporarily) close my current cart, move the existing data and databases to the NEW server, then change the DNS (with a TTL of five minutes). Once everything is on the NEW server, I'll test, hopefully all will be fine, then reopen. I'm still up in the air on whether I'll re-enable the cart on the old server to pick up any areas that the propogation didn't hit quite yet..I may do just that, but hopefully most surfers will see the new server.

OK, so when that is all said and done, and I'm finally on my NEW server, I hope to have the NEW shopping cart setup complete within a week or two, then finally start taking orders. My question (finally) is this - do you see any problem with leaving the old cart semi-operable as far as the categories and items still being there, but disabling ordering and having links redirecting (by click, not refresh) to the home page of the new cart? I don't THINK I'll get whacked for duplicate content, because the new cart's pages are obviously different, though the product titles and descriptions would remain the same. I'm trying to avoid, if at all possible, writing a gigantic 301 script, because I've heard SEO horror stories about that, and because I have approx 4,500 items, and 100+ top level categories, and I don't know how many sub-categories that I'd have to redirect. I'm also going to do an agressive adwords campaign right off the bat to try to get traffic moving in the right direction. I guess I'm trying to choose the lesser of two evils. I've put off doing this for so long now because I have enjoyed great organic search results, but I've put it off long enough now. My old cart (eDatCat) isn't even made or supported any more, thus it's VERY antiquated now. I'll be using a heavily modded X-cart for the new store.

So does my plan sound..uh..sound? I know there's like 30 major SEO violations that could potentially come my way..I'm just trying to figure out the best route available to me.

[Jill]

I don't THINK I'll get whacked for duplicate content, because the new cart's pages are obviously different, though the product titles and descriptions would remain the same.

You don't get "whacked" for duplicate content. You just may see only one or the other version show up in the rankings for the specific keyword phrases that those pages are optimized for.

See the pinned thread in the SEO no-no forum regarding duplicate content for more info.

[-=seth=-]

check with the new server it may be possible to upload the new shopping cart along with a the whole site before you go live, that way you can test it, then when your ready, transfer the domain name to the new server, that way you'll have no down time

Also i should remove all the old pages, google is going to take a few months to find all the new pages, if you do have duplicate content why leave the old pages to compete against the new

[Randy]

Welcome RJC !

What seth said regarding checking to see if you can set it all up in advance for testing on the new server. It'll save you some down time. Even if the host can't do anything, you may be able to pre-test the new site on the new server by tweaking your "hosts" file, assuming you're on a Windows machine. That way you're just instructing your own computer to go to the new server to get to the domain.

Is the new server going to be a Linux/Unix machine or a 'doze machine? I would also give some serious thought to setting up some 301 redirects. If not for every page, at least for the main category pages. Since you're probably changing the site's internal structure completely you'll see some period of time where the engines are forced to pick up the new URIs, which will lead to some pain on the sales side of things. The more you can do to make this process easier for them, the better.

Lastly, if you have the ability to tweak the DNS on the old server you can make the entire process pretty seamless. Basically any DNS record that mentions the IP number of the old server can be changed to reflect the IP number of the new site. This effectively redirects all traffic to the new server immediately, even if someone is using a DNS Cache that needs to be updated.

[RJC]

Thanks for the input..and the welcome

I've been over and over this, and my problem is that the OLD cart won't work on the new server until the domain is pointing there, because there are many variables in the setup files that call for URLs and paths (which will also be different now). I did try a quick and dirty transfer of all the old cart scripts and data files, but of course it didn't work (I am moving from one Unix server to another BTW). I could try to plug in the IP info in place of the domain in the meantime and test it that way (which I may now do) Likewise, I'm having the same issue with X-cart, in that many of the mods I have purchased ONLY work on the domain they are purchased for, so I have cart installs on both servers at the moment, but can only really test many of the mods on the OLD, or current server (I know I could probably contact the mod writers and ask permission be granted for both, but I'll hopefully be moving SOON, so I'll deal with it). I'm also waiting on a solution for accounting data imports..an entirely separate nightmare..and to think this was all born out of a badly handled tech ticket and a thirst for revenge LOL (I will be better off in the long run, so in retrospect, I'm glad..or will be glad..that I did this).

I'll give some thought to doing SOME 301s as well..it wouldn't be that hard, because I do have a list of my old categories, and could throw something together in Excel. I agree about the old competing with the new, but since it's dynamic, it will be all or nothing I'm afraid, and HOPEFULLY the new are a little more SE friendly

As for the DNS stuff, I THINK I can do this, but I'll check.

Thanks again for the input!

[RJC]

OK, quick update...

I just figured out that I CAN'T move my old shopping cart. It used an automated installer that "phoned home" for validation etc. Looking at the store files, it looks like path and domain info is everywhere throughout, so assuming that it would even work, it would require A LOT of manual intervention to make it so. I am now working under these assumptions:

1. Can't move old cart - once I move to new server, it will be using a new cart
2. Old cart was perl/cgi driven, new cart is PHP

I COULD compile a list of old category and product URLs to use for a 301, but I also read in your 301 forum (and had thought this previously), that a big cumbersome .htaccess file would NOT be good thing..and this would be a pretty big file, with 4500 product, and hundreds of category links.

It also looks like a PHP script type redirect is out, since the old cart was cgi, and will be gone anyway.

Do I have any good options here?

[Randy]

I'm going to make a huge assumption and leap of faith here...

Does the old cart retrieve pages with a fairly consistent URI? eg something like:

pagename.ext?var1=aaa&var2=bbb

What I mean by consistent, is the pagename file always the same and are the variables in the same order? (Doesn't really matter if there are the same number of varaibles every time.)

If so, you should be able to use a bit of REGEX pattern matching to pull off all of the redirects with just a rewriterule or two or three, as opposed to having to write 4500 individual redirects.

If you can parse through the current URLs and make note of the URI structures that might appear, then let us know what path needs to be used with the new cart I'm relatively confident we can probably come up with some rewrites to do the job without having to make it a large .htaccess.

[RJC]

You're absolutely correct. All are called from store.cgi, and there are really only a few different variations:

CODE

Category pages:
http://www.domain.com/cgi-bin/store.cgi?user_action=category&category=Category

Category list page:
http://www.domain.com/cgi-bin/store.cgi?user_action=list&category=Category

Item detail page:
http://www.domain.com/cgi-bin/store.cgi?user_action=detail&catalogno=Item#

Static pages (not too many of these, mostly policies and forms and things like that..not real concerned with these..can probably handle these few things with htaccess:
http://www.domain.com/cgi-bin/store.cgi?user_action=link&link=linkname

What I found yesterday was a pretty general cgi script that I tested. I'm thinking I could replace store.cgi on the new server with this. I did test it, and it does work, sending any of the link variations above to a new page, in this case http://www.domain.com/home.php. I'm just not sure if this is the right thing to do. This is the code I tested, which would become store.cgi:

CODE

#!/usr/bin/perl      -w
use strict;
print "Status: 301 Moved Permanantly\n";
print "Location: http://www.domain.com/home.php\n\n";
exit;

Again, it works - it doesn't seem to care about anything that comes after store.cgi? but I'm not real sure if the engines will penalize me or not. I was going to try to redirect everything after store.cgi? with a rewrite rule, because I thought the script wouldn't handle the variables, but it did. Is there a better way to do this in your opinion? I'm not 100% positive what my new ULRs will look like, because I'm using a SEO mod that rewrites everything and assigns URLs based on category and product name...I should know soon though, maybe even tonight.

[Randy]

Piece O cake.

There's only three Regex rewrites in there, so as long as the same sort of info can be fed into the new cart to bring up the right pages it'll be fairly easy. In fact, it might be easier and better just to code it into a Perl/CGI script and let it do the heavy lifting. Been a looooooooong time since I fiddled with Perl, but I can dig out some old books if nobody else remembers how to do it off the top of their head.

What kind of URI structure will the new cart be using? Can we get lucky enough to be able to simply feed it the same or similar values?

[RJC]

I'm not really sure, but I don't think it will be using anything similar unfortunately. MAYBE for the categories, but the items themselves will probably be using a combination of item and category name. I'll try to get a clearer picture tonight or tomorrow, as the SEO mod is one of the last I have to do. Thanks again for the input and help!

[RJC]

OK, I'm back..what a nightmare week. Without warning, after 6 years of use, my old shopping cart just..died. I didn't do anything to it. Someone placed an order, it seemed to double up on them, and the database was corrupted. I tried restoring a recent backup, and it didn't work. Then I tried restoring a backup of the cart script files..big mistake. DOA. So, I decided to bite the bullet and finish up the setup of the new cart. I'm about 90% there now.

I installed the SEO mod, so my categories (which are now the category list pages as well) now bear the category name as part of the url:

CODE

http://www.domain.com/store/category-name

(category name all lower-case)

All products are now the product name with a different directory:

CODE

http://www.domain.com/products/product-name

(again, product name all lower-case)

I won't even get into the sub-cats - there is no logic to how they have been renamed (like category1/1-widgets/, category3/2-widgets/ etc.)

SO:

Formerly:

Category pages:

CODE

http://www.domain.com/cgi-bin/store.cgi?user_action=category&category=Category Name

(mixed case, not sure if it mattered)

Category list page:

CODE

http://www.domain.com/cgi-bin/store.cgi?user_action=list&category=Category Name

(again, mixed case)

are now:

CODE

http://www.domain.com/store/category-name

(category name all lower-case, though all caps/mixed works too)

and


Item detail page:

CODE

http://www.domain.com/cgi-bin/store.cgi?user_action=detail&catalogno=Item#

are now:

CODE

http://www.domain.com/products/product-name

Not holding out much hope for the products, as the item number is not part of the new URL, so again, I guess I'll just bite the bullet on that. If I could at least get the categories redirecting, I'd be a happy camper at this point..and be able to reopen my store!!!

Thanks again for your assistance. I may have to reopen here soon anyway, as I'm already behind the 8 ball

[Randy]

First, I would strongly suggest you head over to ScriptLance or one of the other coder portals to have someone write you a custom Perl/CGI application to handle all of the redirects. The category stuff would be pretty easy, but as long as you're not talking about 10,000+ product pages you should be able to get a custom app built for next to nothing that'll do it all for you.

That said, here's some quick and dirty .htaccess instructions you can slap into your /cgi-bin/ to get at least some of it started. (Note: This is written specifically to be placed in your cgi-bin since I'm sure you have other .htaccess stuff going on.)

CODE

Options +FollowSymlinks
RewriteEngine on
RewriteCond %{QUERY_STRING} category=(.*) [NC]
RewriteRule store.cgi$ http://www.domain.com/store/%1? [R=301,L]

Now for the problems...

#1 Is that really a space in the category name variable? If it is, you've got something else going on in the background because normally a Unix/Linux server will not allow spaces. I'm not sure what the above is going to do given this unknown. Normally the category name would get truncated at the space, causing a 404 to occur.

You really need to give some serious thought to the whole uppercase/lowercase issue. The engines are going to view each of these as completely separate pages, so you'll want to be consistent as humanly possible. Which brings us to...

#2 mod_rewrite doesn't natively have an easy way to deal with forcing URLs to all lowercase characters. If you had httpd.conf access you can do it with something like RewriteMap lowercase int:tolower, but most won't have access to Apache's configuration. To do this strictly via htaccess/mod_rewrite you would literally have to have a separate rule for each letter to force lowercase, then another rule to keep each file request from having to parse through this long list of rewriterules. So 27 rules total just to force lowercase characters. This block of .htaccess instructions would have to be parsed through for each letter in the URL for every file request. You can see why this would be a very, very bad idea.

I'll see if I can't find some of my old Perl books that are probably buried at the back of the bookshelf since a scripted redirect is going to be the best option by far. A scripted solution will be able to handle both of the issues mentioned above, that's why it's the best solution. I'm going to be pretty tied up this whole week, so you might want to put the job out there on ScriptLance, RentACoder, etc. I would think you can probably find someone to do it for you that'll run less than $100 if you don't have too many products to redirect.

[RJC]

I'm going to be pretty tied up this whole week, so you might want to put the job out there on ScriptLance, RentACoder, etc. I would think you can probably find someone to do it for you that'll run less than $100 if you don't have too many products to redirect.

Thanks again for your help. I do have close to 5000 products, so this could become a pretty hefty resource hog. I'd have no problem spending the money, but I'd be worried about a lot of calls to what could be a HUGE cgi script.

As for the spaces, I think you're correct - the actual urls were encoded with %20.

I'll put your code in place for now until I sort this all out - I still have the task of getting my site live once again

[Randy]

Just as another option...

If you have anybody there who is skilled at any scripting language (eg php, asp, etc) you could also just do a flat out redirect of the store.cgi file --no matter what extra variables were included-- to this other file then have it apply the redirection logic. In my experience scripting languages like php and asp are much less load intensive on servers. Plus it might well keep you from having to hire someone who is knowlegeable in Perl redirects. Either way, you should be able to set up some IF loops to shorten the number of lines most calls for the old pages would have to iterate through.

Sure you'd end up having double 301's. But I've never seen that cause any problems for the engines.

[RJC]

CODE

Options +FollowSymlinks
RewriteEngine on
RewriteCond %{QUERY_STRING} category=(.*) [NC]
RewriteRule store.cgi$ http://www.domain.com/store/%1? [R=301,L]

This is working ALMOST perfectly. I've searched and searched and tried and tried..didn't want to bug you again, but I give up...

How do I replace spaces in the orignal string with hyphens (-)?

When I click on my old links in google that have 1 word category names, they are redirecting perfectly to the new category pages, but when I click the old links with spaces (or %20)..I get a redirect to my home page..which isn't the worst thing in the world I guess, but I know it's possible to replace those spaces with -....I just can't figure it out!!!

CODE

http://www.domain.com/cgi-bin/store.cgi?user_action=list&category=cats

works great

CODE

http://www.domain.com/cgi-bin/store.cgi?user_action=list&category=cats%20and%20dogs

redirects to new home page

I think I would need multiple instances as well, to cover 2, 3 or maybe even 4 words (i.e. cats, cats and dogs, cats and dog hats etc.)

I did find this:

CODE

RewriteCond %{REQUEST_URI} ^(.*) (.*)$
RewriteRule ^.*$ %1-%2 [E=space_replacer:%1-%2]
RewriteCond %{ENV:space_replacer} !^$
RewriteCond %{ENV:space_replacer} !^.* .*$
RewriteRule ^.*$ %{ENV:space_replacer} [R=301,L]

But can't figure out how to incorporate it.

Any ideas? Again, I'm happy with what I've got now, but if this is an easy fix, might as well do it.